Skip to main content

Feedback 28-03-2025

Logo FisioFind

FISIO FIND - FEEDBACK 28-03-2025

ÍNDICE

Ficha del documento

  • Nombre del Proyecto: FISIO FIND

  • Número de Grupo: Grupo 6

  • Entregable: #SPRINT 3

  • Miembros del grupo: Alberto Carmona Sicre, Antonio Macías Ferrera, Benjamín Ignacio Maureira Flores, Francisco Capote García, Daniel Alors Romero, Daniel Fernández Caballero, Daniel Ruiz López, Daniel Tortorici Bartús, Daniel Vela Camacho, Delfín Santana Rubio, Guadalupe Ridruejo Pineda, Julen Redondo Pacheco, Miguel Encina Martínez, Francisco Mateos Villarejo, Pablo Fernández Pérez, Ramón Gavira Sánchez, Rafael Pulido Cifuentes.

  • Contribuidores: Alberto Carmona Sicre (autor)

  • Fecha de Creación: 29/03/2025

  • Versión: v1.1

Histórico de Modificaciones

FechaVersiónRealizada porDescripción de los cambios
29/03/2025v1.0Alberto Carmona SicrePrimera versión del documento
29/03/2025v1.1Alberto Carmona SicreFinalización de todos los apartados

1. RESUMEN DEL FEEDBACK POR GRUPO

Primer grupo (Holos):​

Feedback alumnos

  • El enfoque que le han dado a la demo ha sido muy divertido. Además, han usado zoom para mostrar bien las partes de la aplicación menos visibles a gran distancia.

  • Muy buen inicio efectivo.

  • Los aspectos legales del GDPR han gustado.

Feedback recibido (resumen de los comentarios de los profesores)

  • Han empezado muy lento y después ha acelerado descontroladamente, por lo que ha habido partes de la presentación que no se han podido ver ni entender bien. Sugerencia: meter menos diapositivas y practicar más la presentación.

  • El killer opener ha resultado demasiado dramático. Hay que tratar de rebajar el tono para no deprimir al público.

  • Lo de pagos anónimos y personalizados no ha quedado claro.

  • El storyboard de usuarios muy bien. Al de inversores le faltan datos. Hay que poner números, datos, cuánto invierto y cuánto gano. Hay que coordinarse con los dibujos del storyboard, comentar las viñetas. Se anima a que sea la dibujante la que comente los storyboards.

  • Lo del trabajador de la semana está muy bien. Así como hay un hall of fame, puede haber uno de shame.

  • La demo espectacular. El comentar lo que se va a ver en la demo antes de mostrarla es importante, aunque sea por encima. Por otro lado, falta que el admin diga que él es el admin, y no cualquier usuario aleatorio.

  • Las diapositivas 9 y 10 se pueden juntar.

  • Apartado de problemas:

    • Si hace falta recortar el alcance se recorta, porque la carga de trabajo no debe ser mayor de 10 horas semanales.

    • Hay que mostrar una gráfica que muestre cómo ha evolucionado la trazabilidad de la diapositiva 36.

  • Muy bien la gráfica de rendimiento y esfuerzo, así como la de rendimiento individual.

  • Que el testing sea del 0% no es bueno.

Puntos positivos destacados

  • Buen storyboard de usuarios.

  • El destacar al trabajador de la semana.

  • Demo espectacular.

  • Buenas gráficas.

Áreas de mejora sugeridas

  • Gestionar mejor los tiempos.

  • Killer opener más positivo.

  • Hace falta comentar lo que se va a ver en la demo.

  • Las diapositivas 9 y 10 se pueden juntar.

  • Falta una gráfica de evolución de la trazabilidad.

  • Aumentar el porcentaje de testing.

Segundo grupo (Gastrostock):​

Feedback alumnos:

  • El desglose de los costes y los problemas están muy bien detallados.

  • Se ha destacado el uso de Claudette para evitar las cláusulas abusivas en el SLA, recomendado en las píldoras teóricas.

  • Se ha notado la mejoría respecto de la semana anterior.

  • Ha gustado cómo han gestionado el feedback de los usuarios piloto.

Feedback recibido (resumen de los comentarios de los profesores)

  • El inicio efectivo no está bien hilado, ya que la parte de la hostelería es muy amplia, no pueden solo nombrar eso, hay que centrarse también en el problema, y no solo mencionar que la hostelería está muy sacrificada.

  • Hay partes de la presentación que son muy originales, por lo que deberían aplicarlo también en el killer opener.

  • En las diapositivas iniciales de tantas gráficas (4 y 5), podrían aglutinarlas en menos, ya que ayuda a la comprensión.

  • En la demo hay cositas que no se ven, letras muy pequeñas. Hay que usar el zoom.

  • Duda: ¿Cómo evaluáis el rendimiento, solo commits?

    • No, la métrica es también qué ha hecho cada uno, cuántas horas le ha echado. Profesor: Esta forma es un poco floja. En el siguiente sprint deberían evaluar las gráficas que aporta Zenhub.

  • El número de commits no sirve para evaluar correctamente, ya que es muy pervertible.

  • Alabar que tengan una actitud positiva, aunque haya dificultades. Los problemas pasan, y pasan siempre, lo importante es afrontarlos y buscar soluciones, y ellos lo han llevado muy bien.

  • Otra mención a usar Claudette.

  • Al storyboard de inversores le faltan datos. Hay que poner números, datos, cuánto invierto y cuánto gano.

  • La caja de problemas y soluciones está bien.

  • Hay que plantear soluciones que puedan medirse y tienen que mostrar cuánto avanza.

Puntos positivos destacados

  • Presentación con mucha originalidad.

  • Actitud positiva alabable.

  • Uso acertado de Claudette.

  • Caja de problemas y soluciones bien planteadas.

Áreas de mejora sugeridas

  • Hilar mejor el inicio efectivo con la solución que aporta la app.

  • Aglutinar más la información.

  • Demo mejorable.

  • Usar gráficas de Zenhub y no usar el número de commits como métrica.

  • Faltan datos en el storyboard de inversores.

  • Soluciones mejor planteadas.

Tercer grupo (Eventbride):​

Feedback alumnos

  • Matriz de rendimiento muy buena y bien hilada con los empleados de la semana.

  • La música usada en la demo le da un toque.

  • Story boards muy trabajadas.

  • Se ha destacado el team building.

  • Han dejado muy claro de qué va la presentación desde el primer momento.

  • las presentaciones minimalistas, centrándose en el contenido, han gustado.

  • Muy buen el tono y ritmo y las formas de presentar.

Feedback recibido (resumen de los comentarios de los profesores)

  • La demo se veía poco, hay que aumentar el zoom. Error frecuente en las demos: mostrar todo a tiempo real, o acelerado para que se vea todo. Se pueden meter cortes sin problema. La música la quitaría, no aporta mucho. Ayudaría que hubiese distintos narradores cuando hay distintos roles. Además, hay que meter cosas positivas, no hablar de cancelaciones en medio de la demo y cosas así.

  • Justificar las previsiones económicas con el impacto en el mercado. ¿Las líneas están hechas al tuntún? ¿O hay un estudio firme detrás? Recomendación: dar un par de puntos con distintos casos y distintos usuarios y evaluar el porcentaje del mercado que se uniría a nuestra aplicación.

  • Han pasado muy de perfil el pivotar con los clientes. Hay que sacar muchísima más información de los usuarios piloto, sobre todo de los clientes reales, para ordeñar la vaca al máximo, y tener una app mucho más adecuada a lo que piden realmente.

  • El inicio efectivo está muy bien, se nota que los motiva. Hay una historia muy buena detrás.

  • Hablando del rendimiento, es normal que el rendimiento baje en ocasiones. No hay que tener vergüenza a la hora de indicar las desviaciones del rendimiento.

  • En el segundo storyboard, el de inversores, faltan cifras.

  • ¿Hay política de cancelación? Porque ha habido una cancelación en la demo. Han dicho que en semanas siguientes se explayarán.

  • Han mejorado en el seguimiento de los problemas.

  • Las horas mínimas de trabajo en realidad son horas exigidas. Hay que ceñirse a las 10 horas. Es un objetivo.

  • En la diapositiva 36, se han equivocado un poco con las métricas enseñadas, pero Daniel ha contestado bien a la pregunta.

Puntos positivos destacados

  • El inicio efectivo es muy bueno.

  • Seguimiento de problemas muy mejorado.

Áreas de mejora sugeridas

  • Demo muy mejorable: usar distintas voces, quitar la música, etc.

  • Justificar las previsiones económicas.

  • Hay que sacar más información de los usuarios piloto.

  • Faltan cifras en el storyboard de inversores.

  • Ceñirse a las horas mínimas de trabajo.

Cuarto grupo (BORROO):​

Feedback alumnos

  • Muy buen killer opener y demo.

  • Muy bien cómo enseñan las funcionalidades.

  • Han mantenido a don Ramón.

  • Muy buena la métrica del software.

  • Muy bien presentado el uso de la IA.

Feedback recibido (resumen de los comentarios de los profesores)

  • Si el killer opener es generalista, que pueda llegar a cualquier persona, ahí hay problemas de falta de profesionalidad. Es decir, si la demo y el killer opener están en un contexto distinto al de tener como público a alumnos en una clase, puede tener consecuencias muy malas.

  • La demo tiene que estar adecuada a las necesidades y situaciones de los usuarios piloto. Si tienes usuarios piloto mayoritariamente de entre 19 y 25 años, no pongas un taladro como ejemplo.

  • Si realmente se enfocan en algo tan grande, debería haber más objetos en la plataforma de BORROO. ¿Se han hecho transacciones reales? Si, hasta 10. Pablo lo ve poco para el potencial que tienen.

  • El inicio efectivo es bueno, pero falta algo en el elevator pitch. Necesitan una frase que solucione el problema de don Ramón.

  • En la diapositiva 15, está bien aglutinar la información, pero hay que tener en cuenta cómo se muestran las cosas. Si metes animaciones, úsalas para ir mostrando cosas poco a poco.

  • La demo se puede agilizar en muchos apartados, como los formularios de pago, donde puede haber hasta cortes.

  • Son de los pocos que usan Niko Niko. No es un método que sirve mucho para el rendimiento, pero si aporta información acerca del estado emocional.

  • En el feedback de los usuarios piloto, estaría bien mostrar la cantidad, no solo el porcentaje, de los distintos tipos de feedback.

  • La fianza debería haber sido prioritario, y parece que se ha dejado como secundario, cuando es algo trascendental en apps como esta.

Puntos positivos destacados

  • Buen inicio efectivo.

  • Usan el Niko Niko.

Áreas de mejora sugeridas

  • Tener cuidado con las informalidades en el inicio efectivo y la demo.

  • La demo debe estar adecuada al contexto de los usuarios piloto.

  • Les falta algo en el elevator pitch.

  • Usar animaciones para mostrar poco a poco mucha información aglutinada en una diapositiva.

  • La demo debe agilizarse.

  • Mostrar más información del feedback de los usuarios piloto.

Quinto grupo (CAMYO):​

Feedback alumnos:

  • Muy buena presentación, buen storyboard, muy buena demo, comentarios graciosos.

  • Demo acelerada, muy buen contexto de los inversores.

  • Muy buena demo, enlazado con el killer opener, en el final han continuado con la broma.

  • Se ha destacado que en el uso de la IA haya propuestas de cómo reaccionar.

Feedback recibido (resumen de los comentarios de los profesores)

  • Muy muy bien, Carlos se ha levantado y ha aplaudido.

  • Han hilado muy bien todas las partes de la presentación, increíble.

  • Hacen el feedback suyo, recogen todo lo positivo y lo aplican.

  • La demo debe tener un poco más de zoom.

  • ¿El bot de las pull request es el de copilot añadido hace poco? Es un poco parecido, revisa el código de la pr, ve si hay errores y genera un texto descriptivo con los cambios, ayudando al revisor. Comentario de Carlos: Copilot ha metido un bot para revisar las pull request automáticamente, estaría bien tenerlo en cuenta.

  • ¿Hay algún beneficio para los empleados de la semana? El reconocimiento público ya es suficiente (broma). Carlos sugiere incentivos como elegir issues en próximos sprints y cosas del estilo.

  • Muy buenos killer opener y elevator pitch, los dos presentan muy bien.

  • El storyboard transmite muy bien lo que se desea transmitir.

  • La trazabilidad de los problemas está muy bien explicada.

  • Diapositiva 18: se han autoevaluado, cuando debería haber ya métricas de rendimiento. Se evalúan el autoesfuerzo. Es un tanto raro.

  • El rendimiento podría evaluarse con métricas ya mostradas.

Puntos positivos destacados

  • La presentación en general.

  • Muy bien hilada toda la presentación.

  • Se nota que tienen en cuenta todo el feedback generado en las clases.

  • Muy buenos killer opener y elevator pitch.

  • Los presentadores presentan muy bien.

  • El storyboard está muy bien trabajado.

  • Trazabilidad de problemas bien explicada.

Áreas de mejora sugeridas

  • Más zoom en la demo.

  • Hacer uso de incentivos para motivar.

  • Rendimiento evaluable con métricas ya mostradas.

Sexto grupo (FISIO FIND):​

Feedback alumnos

  • Genial, todo muy profesional.

  • Perfectamente desplegable.

  • Han destacado que haya una persona grabando la presentación.

  • Destacar la demo, muy bueno todo.

Feedback recibido (resumen de los comentarios de los profesores)

  • El anuncio final está realmente bien. Además nos vemos muy profesionales.

  • Hay que diferenciar entre anuncio y demo. No hace falta conectarlas.

  • Con respecto al análisis de costes, el análisis en la gráfica es raro, porque las HU deben ser muy variables según lo que quieren los usuarios. Si quieren hacer una estimación de puntos de HU puede estar bien, pero es bastante complejo. Depende mucho del feedback. Pablo estaría dispuesto a dos finales: un final de características avanzadas (mucho esfuerzo), y otro final de mayor captación de usuarios piloto (Bajo esfuerzo).

  • Buen inicio efectivo y elevator pitch. No hace falta cambiarlos semana a semana, si funciona, funciona.

  • La demo está muy bien hecha. Además, proporcionar contexto también en el anuncio, para Cristina, está correcto.

  • Tenemos una funcionalidad más compleja que los demás, pero muy bien desarrollada y llevada.

  • En cuanto al bajo ratio de respuestas de los usuarios piloto, hemos dado muy poco margen para responder. Es más problema nuestro.

Puntos positivos destacados

  • Presentación, demo y anuncio muy profesionales.

  • Buenos killer opener y elevator pitch.

  • Proporcionar contexto en el anuncio.

  • Hemos sabido gestionar bien la compleja funcionalidad.

Áreas de mejora sugeridas

  • Reorganizar el análisis de coste respecto a los puntos de HUs.

  • Dar más margen de respuesta a los usuarios piloto.

2. ANÁLISIS DEL FEEDBACK

2.1. TENDENCIAS GENERALES​

Factores comunes en los comentarios de los profesores

  • Presentaciones iniciales potentes: La mayoría de los grupos ha hecho un esfuerzo por crear un killer opener llamativo. Sin embargo, se destaca la necesidad de que esté bien alineado con el contexto y el público. En algunos casos, se señala que el tono es demasiado dramático, informal o genérico.

  • Storyboards de inversores incompletos: Casi todos los grupos han recibido comentarios sobre la falta de datos cuantitativos en los storyboards dirigidos a inversores (cuánto se invierte, cuánto se gana).

  • Problemas de visualización en las demos: Es un problema recurrente que las demos no se vean bien (letras pequeñas, poco zoom, demasiado rápidas o sin cortes). También se menciona la importancia de contextualizar lo que se va a ver antes de mostrarlo.

  • Uso y evaluación de métricas: Hay cierta crítica generalizada al uso de métricas poco robustas como el número de commits. Se sugiere en su lugar usar herramientas como Zenhub para tener métricas más sólidas. También se valora cuando se mide la trazabilidad de los problemas y el rendimiento.

  • Gestión del feedback de usuarios piloto: Se valora mucho cuando los equipos recogen bien el feedback de usuarios piloto y lo utilizan de forma activa para pivotar o mejorar. Al mismo tiempo, se señala como área de mejora la necesidad de sacar mayor provecho de esa información (más cantidad, más profundidad).

Puntos de fortaleza general en los equipos

  • Buen uso del storytelling en los storyboards los dirigidos a usuarios.

  • Esfuerzo por hacer presentaciones dinámicas, con demos entretenidas.

  • Uso de herramientas de trazabilidad y planificación, como Zenhub, gráficos de rendimiento, o métricas visuales.

Áreas de mejora recurrentes

  • Mejorar la visibilidad de las demos: añadir zoom, eliminar partes irrelevantes o acelerar con cortes.

  • Incluir más datos cuantitativos en el storyboard de inversores.

  • Evitar métricas engañosas o poco relevantes como commits para evaluar el rendimiento.

  • Aprovechar mejor el feedback de usuarios piloto: obtener más respuestas, analizarlas mejor, y aplicarlas al producto.

  • Agilizar la demo y adecuarla al público objetivo.

  • Revisar el análisis de costes.

2.2. COMPARACIÓN DEL FEEDBACK DE NUESTRO GRUPO VS LOS OTROS​

¿Qué estamos haciendo bien en comparación con otros?

  • Alta profesionalidad: Se ha destacado que tanto la presentación, como la demo y el anuncio final están a un nivel muy profesional, algo que no todos los grupos han logrado.

  • Demo muy sólida: A diferencia de otros grupos, donde se critica la falta de zoom o el ritmo demasiado rápido, nuestra demo ha sido muy bien valorada.

  • Elevator pitch y killer opener sólidos: Se ha confirmado que funcionan bien, por lo que no es necesario reinventarlos cada semana.

  • Gestión adecuada de la complejidad técnica: A pesar de tener una funcionalidad más compleja que otros grupos, la hemos sabido llevar muy bien, lo cual se ha valorado especialmente.

¿Qué aspectos debemos mejorar respecto a los demás?

  • Análisis de coste más riguroso: Se nos ha señalado que la gráfica de análisis de coste según HU es algo confusa. Otros grupos también tienen este problema, pero deberíamos ser de los que lo resuelven con más claridad.

  • Feedback de usuarios piloto: Debemos trabajar en tener la aplicación funcionando mucho antes para ampliar las respuestas de ese feedback.

  • Explorar vías de mejora en el storytelling hacia inversores: Al igual que todos, podemos reforzar nuestro storyboard de inversores incluyendo cifras claras de inversión y retorno.

COMENTARIOS FINALES​

  • Simplemente se ha destacado lo bien que se han hecho las demos.

PRÓXIMA SEMANA​

  • Introducción:

    • Killer opener de 1 minuto.

    • Elevator pitch de 30 segundos.

    • Presentar los competidores más al grano.

    • Storyboards.

    • Customer agreement, licencias, términos y condiciones del servicio, evitar cláusulas abusivas, acuerdos de nivel de servicio, implicaciones otras apis, pricing, gdpr.

    • TCO, CapEx OpEx, github, optimista, realista y pesimista. Mejorar con el feedback dado.

    • Equipo igual: resumen, roles, commitment agreement status (ver si se está cumpliendo).

  • Demo

    • Mejorar la calidad visual y auditiva, así como una buena diferenciación de roles: usar distintas voces si hay distintos usuarios.

  • Prototipo: decir si ha mejorado la usabilidad o interfaz (experiencia de usuario) y decir lo que estamos haciendo para tratar las regulaciones.

  • Retrospectiva 40%-50%

    • Casi lo mismo.

    • Añadir gráficas rendimiento/esfuerzo: Mucho esfuerzo poco rendimiento, poco esfuerzo mucho rendimiento, etc.

    • Gráficas rendimiento personal, análisis software.

    • En el apartado de Problemas igual pero decir, además del problema, el estado de este (si es de antes, solucionado, no solucionado, etc), las acciones concretas y ver alguna forma de evaluar esa solución. Analizar las soluciones. Añadir unas lecciones aprendidas del análisis.

  • Gestión de usuarios piloto: Nada nuevo parece.

    • Gestión del feedback, comunicación.

  • Retrospectiva sprint 3:

    • Análisis de código, rendimiento, problemas encontrados. Hay que decir cómo van las soluciones, hay que explicar para cada problema las acciones CONCRETAS (no mejorar las cosas, no reunirnos más, si puede ser reunirnos una vez más para reducir x) y después el cómo sabéis que está funcionando (poniendo medidas como el número diario de pull requests) hay que poner un objetivo (medir si la media de pull requests es tanto, ese sería el objetivo, dentro de x días, así sí se puede decir si están funcionando o no).

      • Los problemas se repiten, hay que tomarse en serio el cómo se mide.

    • Hacer plan de pruebas previo al WPL.

  • Reloj.

  • Acciones en un ranking que se va a hacer, categorizar el feedback y priorizarlo.

  • Replanificación con los apartados de seguridad.

  • Entrega PPL: publicidad, de cara al lanzamiento y refinamiento del MVP.

  • Uso de la IA:

    • Decir que si se ha mejorado el uso de la IA desde el principio, lecciones aprendidas, alucinaciones.

    • Evitar generalizaciones.

  • Diapositiva final.

NUEVO: anuncio en video, demo hincapié en regulaciones y usabilidad, plan de pruebas para el WPL, seguimiento cuantitativo de la evaluación de las soluciones a problemas, categorización del feedback, y lo dicho en la entrega para el PPL.

3. CONCLUSIONES Y OBSERVACIONES

  • El feedback global es muy positivo hacia nuestro grupo (Fisio Find), destacando la profesionalidad, la calidad de la demo, la organización y el cuidado en los detalles. Esto nos sitúa como uno de los equipos con mayor madurez en la presentación del proyecto.

  • A nivel general, se observan tendencias comunes en los comentarios de los profesores, como la necesidad de mejorar los storyboards para inversores, el uso adecuado de métricas de rendimiento, y la optimización de las demos (más zoom, cortes, menos aceleración).

  • Nuestro grupo ha acertado en muchas decisiones clave, como mantener un killer opener sólido, diferenciar claramente entre demo y anuncio, y gestionar con éxito una funcionalidad técnicamente compleja. Todo esto genera una imagen de equipo profesional y bien cohesionado.

  • Aunque la respuesta de los usuarios piloto ha sido baja, se reconoce que se debe a factores logísticos (poco margen de tiempo). Aun así, mejorar la recolección y explotación del feedback de usuarios será clave para próximos sprints.

  • El análisis de costes y las métricas de esfuerzo pueden reorganizarse y clarificarse, diferenciando claramente la autoevaluación del esfuerzo de las métricas objetivas de rendimiento. Esto evitará confusiones y dará mayor solidez al apartado de análisis del equipo.

  • Incluir datos cuantitativos en el storyboard de inversores (costes, beneficios, proyección de mercado) es un paso necesario para estar al nivel de exigencia que se ha planteado de forma transversal en todos los equipos.

  • Si bien el feedback sugiere que no hace falta cambiar elementos que funcionan bien (como el killer opener), debemos estar atentos a que el mensaje siga conectado con el progreso del proyecto y no pierda actualidad o coherencia con el avance técnico.

Aprobado por:
Scrum Master: Antonio Macías Ferrera
Secretario: Alberto Carmona Sicre